REMARKS 

Overview of the Office Action 

Claims 1-4 and 9-14 have been rejected under 35 U.S.C. § 103(a) as unpatentable over 
U.S. Patent No. 7,320,026 ("Adamczyk") in view of ("RFC 3026"). 

Claims 5-8 have been objected to as depending from a rejected base claim, but would be 
allowable if rewritten in independent form including the base claim and any intervening claims. 

Status of the claims 

Claims 15, 16, and 17 have been newly added. 
Claims 1-17 are now pending. 

Interview Summary 

Applicants' agent conducted telephone interviews with the Examiner on August 6, 2009 and 
August 12, 2009. 

During the first telephone interview, Applicants' agent presented arguments regarding the 
patentability of independent claim 1 in view of Adamczyk and RFC 3026. 

The Examiner agreed that Adamczyk and RFC 3026 fail to teach or suggest that the test of 
the validity of the destination telephone number (NTEL) of the request (R) is executed 
automatically prior to forwarding the request to the domain name server, and that the request is 
only forwarded to the domain name server if the test is passed, as recited in claim 1 . 

However, The Examiner stated that he did not understand the meaning of the phrase " local 
to the requesting machine (H)" and recommended amending claim 1 to further define the term 
"local". 
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The Examiner requested that Applicants' reiterate the arguments presented during the 
interview in a formal response. 

During the first interview, the Examiner stated that he wanted to further consider claim 9 
in view of Applicants arguments, and therefore suggested a second interview at a later date. 

During that second interview, Applicants' agent presented arguments regarding the 
patentability of independent claim 9 in view of Adamczyk and RFC 3026. 

The Examiner agreed that Adamczyk and RFC 3026 fail to teach or suggest a means for 
forwarding the request (R) from the requesting machine (H) to the domain name server only if 
the control means (DC) determine that its destination telephone number (NTEL) has passed the 
validity test, as recited in claim 9. 

The Examiner again stated, however, that he did not understand the meaning of the phrase 
" local to the requesting machine (H)" and recommended amending claim 9 to further define the 
term "local". 

The Examiner again requested that Applicants' reiterate the arguments presented during 
the second interview in a formal response. 

The Examiner stated that the "means (DR) for receiving requests (R)" recited in claim 9 is 
unclear, and could be interpreted as software, which is not patentable, and thus asserted that 
claim 9 is unpatentable under 35 U.S.C. 101. The Examiner indicated that if claim 9 is not 
amended to clarify the meaning of the means (DR) for receiving requests, he would reject claim 
9 under 35 U.S.C. 101. 
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Rejection of claims 1-4 and 9-14 under 35 U.S.C. § 103(a) 

The Office Action states that the combination of Adamczyk and RFC 3026 teaches all of 
Applicants' recited elements. Applicants disagree. 

Independent claim 1 recites that "a prior test of the validity of the destination telephone 
number (NTEL) of the request (R) is executed automatically and locally to the requesting 
machine (H) relative to a telephone number database (BD) local to the requesting machine (H) in 
order to forward the request (R) from the requesting machine (H) to the domain name server only 
if its destination telephone number (NTEL) passes said test", which Adamczyk and RFC 3026, 
whether taken alone or in combination, fail to teach or suggest. 

More specifically, Adamczyk and RFC 3026 fail to teach or suggest that Applicants' 
recited test of validity is executed locally to the requesting machine, and that Applicants' recited 
test of validity is executed prior to the forwarding of the request (if any) to the DNS. 

Adamczyk discloses a method for transferring voice messages between proprietary voice 
message systems over the Internet (see col. 1, lines 56-64 and Fig. 3 of Adamczyk). According 
to Adamczyk, a requesting machine sends one or more requests for subscriber address 
information to a DNS (ENUM server 318) wherein the request identifies a telephone number for 
the subscriber (in ENUM format) (see col. 7, lines 1-8 of Adamczyk). In return, the DNS 
provides the requesting machine with the IP address of the server LDAP (and database) 322 
associated with the provided phone number (see col. 7, lines 9-15 of Adamczyk). 

Once the IP address of the appropriate server/database 322 of Adamczyk has been 
identified, the requesting machine can obtain from the server/database 322 the specific domain 
name address and routing information necessary to forward the voice message to the destination 
subscriber (see col. 7, lines 31-39 of Adamczyk). Further, it is essential that the requesting 
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machine of Adamczyk sends its request to the DNS prior to communicating with the database 
322 in order to obtain the IP address of the database 322 (see col.7 3 lines 3-8 of Adamczyk). 

The Examiner asserts that the computer 304 (or 306) of Adamczyk corresponds to 
Applicants' recited requesting machine (H) and that the LDAP server/database 322 of Adamczyk 
corresponds to Applicants' recited database (BD) that is local to the requesting machine. 

Adamczyk teaches that the DNS 3 1 8 determines, based on a request received from 
platform 308, which LDAP database 322 is "associated with the provided phone number" (see 
col. 7, lines 4-18 of Adamczyk). To accomplish this, the DNS 318 performs internal lookup 
functions and/or external requests, which means that DNS 318 tests the validity of the request 
remotely from the requesting machine. 

If the request is valid, the DNS 3 1 8 determines the address information (such as the IP 
address) for the appropriate LDAP server/database 322. Then platform 308 communicates with 
that particular LDAP server/database to locate the specific domain name address and routing 
information needed to send the message to the intended recipient user B (see col. 7, lines 31-39 
of Adamczyk). 

If, however, the request is not valid, then DNS 318 is unable to identify the corresponding 
LDAP server/database 322. 

The platform 308 of Adamczyk acts as an interface between User A (the caller) and DNS 
318, and corresponds to the requesting machine in the sense of Applicants' recited invention (i.e. 
the machine that sends the request to the DNS 3 1 8). 

As such, it is apparent that Adamczyk fails to teach or suggest that a validity test is 
performed local to the requesting machine (308). Further, Adamczyk also fails to teach or 
suggest that the LDAP database 322 is local to the requesting machine (308). Additionally, since 
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both the DNS 318 and LDAP 322 communicate with platform 308 over the Internet, it is clear 
that the test of validity is done remotely from the requesting machine 308. 

Consequently, Adamczyk teaches away from the step of performing locally a test of 
validity of the destination telephone number prior to sending the request to the DNS. A person 
skilled in the art would immediately understand that it is essential in Adamczyk that the 
requesting machine first sends its request to the DNS (whether or not the request is valid) in 
order to gain access to the appropriate database 322. Hence, there is no need for, or reason to 
provide, a local test of the validity of the destination telephone number prior to sending the 
request to the DNS in the system of Adamczyk. 

In contrast to the configuration taught by Adamczyk, Applicants' recited device is disposed 
in the requesting machine, and hence the test of validity is executed locally to (i.e., on) the 
requesting machine. Further, Applicants' recited database (BD) is local (i.e., either in or 
connected via a LAN) to the requesting machine (H) (see Figs. 1 and 2, and paragraphs [0056] 
and [0057] of Applicants' published specification). This results in significant improvements in 
reduced communications/signaling traffic (e.g., over the Internet or the like) and processing 
overhead. 

Applicants submit that one skilled in the art would fully appreciate and understand the 
meaning of the terms "local" and "locally" recited in Applicants' claims and as contrasted to the 
teachings of Adamczyk. For example, the phrases "locally to the requesting machine" and "local 
to the requesting machine" clearly describe that the request is executed, or that the database is 
located, respectively, at the requesting machine. Applicants' therefore see no reason to further 
describe or limit these terms in the claims. 

In response to Applicants' previous arguments, although the Examiner acknowledges that 
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Adamczyk does not explicitly disclose a prior test of the validity of the destination telephone 
number of the request as recited in Applicants' claims, the Examiner regards the claimed prior 
test of validity "as common practice to verify the appropriate mapping of the destination address 
or destination telephone number prior to establishment of the communication session". 

Applicants submit that the Examiner is confusing two different communication protocols. 
Specifically, the Examiner appears to be confusing (i) verifying the validity of a phone number at 
the DNS level prior to establishing a session of communication between the two entities (i.e., the 
prior art configuration), and (ii) verifying the validity of a phone number locally to the requesting 
machine prior to forwarding the request (or not) to the DNS server (i.e., Applicants' recited 
invention). 

As described in paragraphs [0003]-[0005] of Applicants' published specification, the DNS 
servers known in the art are configured to receive all of the requests from the requesting 
machine, regardless of whether the requests are valid or invalid. 

The DNS server is then able to determine whether the requested phone number corresponds 
to a valid domain name and, if so, forward to the requesting machine the records associated with 
that domain name. 

Accordingly, the DNS servers known in the art are tasked with verifying the validity of 
any requested phone number before establishing a session of communication (e.g., between the 
caller and the calling party). 

Adamczyk thus discloses no more than a protocol for communication between a 
requesting machine (platform 308) and a DNS server (318), as is known in the art. 

In contrast to Adamczyk, Applicants' recited invention prevents invalid requests from 
reaching the DNS. According to Applicants' recited invention, only valid requests are forwarded 
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to the DNS. In this manner, the DNS not burdened with the processing of invalid requests, 
resulting in an advantageous reduction in the traffic through the network that is caused by invalid 
requests. This is why it is essential in Applicants' invention to perform the prior test of validity 
locally to the requesting machine. 

In support of his assertion, the Examiner cites col. 7, lines 10-14 of Adamczyk, which 
reads "the DNS/ENUM server 3 1 8 may perform any number of internal lookup functions and/or 
external requests to locate the address information, such as the IP address for LDAP server 322". 

The discussion in Adamczyk cited by the Examiner simply describes conventional DNS 
servers, which are also described in Applicants' specification. 

Applicants' recited invention reduces the tests of validity (or any other lookup functions 
or external requests) that must be performed by the DNS. This is achieved by sending to the 
DNS server only valid requests, as explained in Applicants' specification. Adamczyk clearly 
teaches that all requests are sent to the DNS server. 

Further in support of his assertion, the Examiner cites col. 7, lines 14-18 of Adamczyk, 
which reads "the DNS/ENUM server 318 maintains mapping information for the requested 
phone numbers. In such an environment new LDAP servers must register or otherwise alert the 
DNS/ENUM server 318 of their existence and their IP address". 

The cited passages of Adamczyk simply confirm that it is the duty of the DNS server 318 
to perform all of the tests of validity, and that no such tests are performed locally to the 
requesting machine. In other words, Adamczyk teaches that all requests, whether valid or 
invalid, are sent to the DNS server 318, as contrasted with Applicants' recited invention in which 
only valid requests are sent to the DNS server. 

As mentioned above, the Examiner concedes that Adamczyk fails to teach or suggest "a 
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prior test of the validity of the destination telephone number (NTEL) of the request (R) is 
executed automatically and locally to the requesting machine (H) relative to a telephone number 
database (BD) local to the requesting machine (H) in order to forward the request (R) from the 
requesting machine (H) to the domain name server only if its destination telephone number 
(NTEL) passes said test", as recited in Applicants' claim 1 . 

The Examiner cites RFC 3026 as teaching an entity (to which E.164 test codes have been 
assigned) that is responsible for providing appropriate assignment information to DNS 
administrators. The Examiner asserts that this teaching implies that prior to any type of 
information being routed, there must be a check capability to verify the validity of the destination 
telephone number, including format, country code, and domain name. The Examiner further 
asserts that it would have been obvious to incorporate these teachings of RFC 3026 into the 
teachings of Adamczyk for the purpose of clearly defining the ENUM format, including the 
country code, and verifying or testing this format prior to actual call processing. Applicants 
disagree. 

RFC 3026 discloses a method for administering and maintaining the E.164 based resources 
in the DNS as related to the ENUM protocol (see Abstract). RFC 3026 also discloses that the 
ITU (International Telecommunication Union) has the responsibility of providing assignment 
information to DNS administrators. According to RFC 3026, the list of spare codes should be 
provided to the DNS administrators. Further, "test codes" are also assigned to various entities. 
These entities are considered as being responsible "for providing any appropriate assignment 
information 0 to DNS administrators (see page 2, second bullet of RFC 3026). 

In Applicants' previous arguments, Applicants erroneously cited RFC 2602 in support of 
their arguments. Applicants instead meant to cite RFC 2606, a copy of which is attached hereto. 
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According to RFC 2606 (June 1999), "test codes" correspond to unused top level domain 
names which are reserved for testing local DNS code and configuration (see page 2, section 2 of 
RFC 2606). RFC 2606 also mentions that ".test" domain names are recommended for use in 
testing of current or new DNS related code. In others words, the test codes are meant to be used 
for internal tests of the local DNS code and/or configuration. However, these test codes would 
not be sufficient to allow tests of validity to be performed locally to a requesting machine. 
Accordingly, the test codes of RFC 3026 have nothing to do with testing the validity of specific 
destination telephone numbers, as recited in Applicants' claim 1. 

Further, although RFC 3026 mentions that assignment information should be provided to 
the DNS administrators, no further details regarding this information are provided. Therefore, 
one skilled in the art would not, and could not, conclude that RFC 3026 teaches that prior to any 
type of information being routed to a requestor, there should be a check to verify the validity of 
the destination telephone number, including format, country code, and domain name. 

RFC 3026 specifies that the International Telecommunication Union "will provide spare 
code lists to DNS administrators for purposes of clarification" (see bottom of page 2 to top of 
page 3 of RFC 3026). 

This means that each DNS known in the art has sufficient information, based on the 
provided spare code list, to determine whether a requested domain name is valid or invalid (i.e., 
used or unused). This again confirms that, in conventional arrangements, any test of validity is 
to be performed on all reqests at the DNS level, and not at the requesting machine level. 

Additionally, although It is true that domain names are segmented into a number of 
codified zones (e.g., domain zone, country zone, and national zone), this does not change the fact 
that, in arrangements known in the art, tests of validity are always performed by the DNS, and 
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not local to (i.e., on) the requesting machine, as recited in Applicants' claim 1 . 

RFC 3026, therefore, also fails to teach or suggest "a prior test of the validity of the 
destination telephone number (NTEL) of the request (R) is executed automatically and locally to 
the requesting machine (H) relative to a telephone number database (BD) local to the requesting 
machine (H) in order to forward the request (R) from the requesting machine (H) to the domain 
name server only if its destination telephone number (NTEL) passes said test", as recited in 
Applicants' claim 1. 

Morever, even if one skilled in the art were to somehow conclude that RFC 3026 does 
teach Applicants' above-described feature, the person of skill would not consider or be motivated 
to combine the teaching of RFC 3026 with the teachings of Adamczyk because, as discussed 
above, Adamczyk teaches away from the step of performing locally a test of validity of the 
destination telephone number prior to sending the request to the DNS. Instead, Adamczyk 
explicitly teaches that the requesting machine must first send the request to the DNS 3 1 8 
(whether or not the request is valid) in order to gain access to the appropriate database (LDAP 
322). Hence, there is no need for, or reason to provide at the requesting machine, a local test of 
the validity of the destination telephone number prior to sending the request to the DNS 3 1 8 in 
the system of Adamczyk. 

Adamczyk and RFC 3026, therefore, whether taken alone or in combination, fail to teach 
or suggest "a prior test of the validity of the destination telephone number (NTEL) of the request 
(R) is executed automatically and locally to the requesting machine (H) relative to a telephone 
number database (BD) local to the requesting machine (H) in order to forward the request (R) 
from the requesting machine (H) to the domain name server only if its destination telephone 
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number (NTEL) passes said test", as recited in Applicants' claim 1. Accordingly, Applicants 
claim 1 is deemed to be patentable over Adamczyk and RFC 3026 under 35 U.S.C. § 103(a). 

Furthermore, because both Adamczyk and RFC 3026 fail to teach or suggest that a test of 
validity is executed prior to the forwarding of the request (if any) to the DNS, as recited in claim 
1, Applicants' recited invention is patentable over Adamczyk and RFC 3026 for this reason 
alone and there is again no need to further define or limit the recited terms "local" and "locally". 

Independent claim 9 recites limitations similar to those of independent claim 1 and is, 
therefore, deemed to be patentably distinct over Adamczyk and RFC 3026 for at least those 
reasons discussed above with respect to independent claim 1 . 

With further respect to independent claim 9, and as discussed above, during the second 
telephone interview the Examiner stated that the "means (DR) for receiving requests (R)" recited 
in claim 9 is unclear and could be interpreted as software, which is not patentable, and asserted 
that claim 9 is therefore unpatentable under 35 U.S.C. §101 . The Examiner indicated that if 
claim 9 is not amended to clarify the means (DR) for receiving requests, then claim 9 would be 
rejected under 35 U.S.C. §101 . Applicants disagree with the Examiner's interpretation of the 
above-mentioned limitation and submit that a rejection under 35 U.S.C. §101 would be improper 
for the reasons provided below. 

Applicants' claim 9 is directed to a device, only part of which is the recited means (DR) 
for receiving requests. The device of claim 9 also includes a database, which inherently includes 
a memory. Thus, claim 9 is clearly directed to a physical device, which may include software, 
and is not directed software alone. Claim 9 should not accordingly be rejected under 35 U.S.C. 
101. 
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When means plus function claim language is used to define the characteristics of an 
invention, such language must be interpreted to read on only those structures or materials 
disclosed in the specification and equivalents thereof that correspond to the recited function. 
According to the specification at paragraph [0056], the means (DR) for receiving requests is an 
interface, which is hardware . For this reason as well, then, claim 9 cannot properly be 
interpreted as being directed to only software, and a rejection under 35 U.S.C. §101 would be 
improper. 

Independent claim 13 recites limitations similar to those of independent claim 1 and is, 
therefore, deemed to be patentably distinct over Adamczyk and RFC 3026 for at least those 
reasons discussed above with respect to independent claim 1 . 

Independent claims 12 and 14 recite limitations similar to those of independent claim 9 
and are, therefore, deemed to be patentably distinct over Adamczyk and RFC 3026 for at least 
those reasons discussed above with respect to independent claim 9. 

Claims 2-4 and 10-11, which variously depend from independent claims 1 and 9, 
incorporate all of the limitations of the corresponding independent claim and are, therefore, 
deemed to be patentably distinct over Adamczyk and RFC 3026 for at least those reasons 
discussed above with respect to independent claims 1 and 9. 

Newly added claims 15-17 

Claims 15-17 have been newly added. Support for the newly added dependent claims 15- 
17 can be found in Fig. 1 and paragraph [0056] of Applicants' published specification. 

Claims 15-17, which depend from independent claims 1 and 9, incorporate all of the 
limitations of the corresponding independent claim and are, therefore, deemed to be patentably 
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distinct over Adamczyk and RFC 3026 for at least those reasons discussed above with respect to 
independent claims 1 and 9. 



In view of the foregoing, Applicants respectfully request reconsideration, withdrawal of 
all rejections, and allowance of all of the now-pending claims. 

Should the Examiner have any comments, questions, suggestions, or objections, the 
Examiner is respectfully requested to telephone the undersigned to facilitate a resolution of any 
outstanding issues. 

It is believed that no fees or charges are required at this time in connection with the 
present application. However, if any fees or charges are required at this time, they may be 
charged to our Patent and Trademark Office Deposit Account No. 03-2412. 



Conclusion 



Respectfully submitted, 

COHEN PONTANI LIEBERMAN & PAVANE LLP 




Lance J. Lieberman 



Reg. No. 28,437 
551 Fifth Avenue, Suite 1210 
New York, New York 10176 
(212) 687-2770 



Dated: Septembers, 2009 
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